REMARKS 

Claims 1-3, 6, 9-14, 17-57 are pending. Claims 1, 3, 6. 9, 10, 12, 13, 14, 18, 23, 
28, 30-33, 35-36, 46, 50-51 have been amended. Claim 22 has been canceled and claims 
4-5, 7-8 had previously been canceled. New claims 55-57 have been added including 
new independent claim 57. 

Regarding the examiner's section 101 rejection of claims 1-3, 6, 9-38 and 40-53, 
Applicant has adopted the examiner's suggestion and added "non-transitory" before 
"computer readable medium 5 ' in the preamble of independent claims 1 and 14, 
Accordingly, it is respectfully suggested that the section 101 rejection is now overcome 
for all relevant claims. 

Regarding the section 112 rejection of claims 22 and 28, Applicant has canceled 
claim 22 and rewritten it as new independent claim 57 and has amended claim 28 to fill 
in. the missing elements, Consequently, the section 112 rejections have been overcome. 

Regarding the section 103 prior art rejections, and in order to advance prosecution 
of this case, Applicant has amended claims 1 and 14, For example, Applicant has 
amended claim 14 to change the description of the inbound lists from "only one of which 
is active at a given time" to "only one of which is active for a given request by a client". 
This claimed limitation contrasts with Humes' Local- Allow list and Deny list in which 
Humes at least sometimes uses both of these lists for the same inbound request by a 
client. Accordingly, Humes does not meet the elements of the claimed invention (and 
neither does the remaining cited prior art). Applicant has also amended claim 1 with 
respect to inbound lists to recite such that use of one inbound list is independent of an 
outcome of use of the other inbound list . Analogously, Applicant has amended claim 14 
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to recite a checking of the content of one of the conte nt inbound lists indep endent of an 
outcome of a checking of the content of the other content inb ound list. In contrast to 
claims 1 and 14, in Humes, column 6 lines 30-32, it states that u [i}f the URL is not in the 
Local- Allow list, decision block 320 checks to see if the URL is in the Deny List." For 
this additional reasons, claim 1 does not meet the limitations of the claimed invention of 
independent claims 1 and 14. 

Since claim 1 is written disjunctively (referring to the engine being either capable 
of using . . . outbound lists or capable of using . . .inbound lists or both), Applicant has also 
amended claim I to recite that the domain filtering engine is capable of using a friendly 
outbound list and an unfriendly outbound list such that use of one outbound list is 
independ ent of an outcome of use o f the other outbound list . 

Applicant has further amended claim 1 to recite that the domain filtering engine is 
"capable of using a friendly inbound list and an unfriendly inbound list in any order". 
Similarly, claim 14 has been amended to recite that the content filtering engine is 
"capable of performing content filtering including checking a content of a requested 
document against a friendly content inbound list? and an unfriendly content inbound list 
in any order". The friendly content inbound list may be checked before or after the 
unfriendly content inbound list. In contrast to this limitation of claims 1 and 14, Humes 
always uses its Local- Allow and Deny lists in a particular sequential order in which, first 
the Local-Allow list is used and then the Deny List may be used (depending on the 
outcome of the Local-Allow list). See Humes column 6 lines 1 8-33. The sequential 
order of Humes' lists also carries through to Humes' third layer of domain/URL filtering 
(a score-based dictionary list) as seen in Humes column 6, lines 39-40; Figure 3, block 
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324, 326, and 334 and column 2, line 62 through column 3, line 40, Humes claim 18, in 
which processing is also in a sequential order. Accordingly, for this additional reason, the 
claimed invention of claims 1 and 14 is distinguishable over Humes (and over the rest of 
the cited prior art). 

The original Specification supports the above amendments to claims 1 and 14, 
For example, regarding the amendments reciting using the two inbound lists "in any 
order" and the amendments reciting that using one inbound (or outbound) list is 
independent of the outcome of using the other inbound (or outbound), it states multiple 
times in the Specification (see for example Spec, at p. 11 last full para, and original claim 
1); that the friendly inbound, unfriendly inbound, friendly outbound and unfriendly 
outbound list are each uniquely configured for each user account. If each list is uniquely 
configured per account, then it is implied that one list is not configured based on how 
another list is configured. Moreover, nothing in the Specification suggests that one or the 
other list cannot be used because it violates a sequence - no sequence is mentioned 
anywhere in the patent application. Furthermore, nowhere in the patent application is 
there a suggestion that a list can only be used after evaluating the results of the use of the 
other list. Nothing like that is found in the patent application. Accordingly, these 
amendments are supported by the description of the lists in the patent application. 

With respect to the amendment in claim 14 reciting that only one of the inbound 
lists is active for a given request of a client, this is supported by FIGS. 6A-6D which 
show a only a friendly (content) inbound list and not a friendly and unfriendly list or else 
only an unfriendly (content) inbound list and not a friendly and unfriendly list, in 
operation in relation to a single particular request by a client. Only one list is active at a 
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given time (as indicated in the Specification) and the drawings are showing one list being 
active for a given client request. Furthermore, the drawings of the parent case 
(US7587499) which is incorporated by reference, show one inbound list active for a 
particular data flow, i.e. a particular request (e.g, FIG. 1 A of parent). See also parent at 
column 1 lines 39-42. Moreover, the whole thrust of the pending Specification is based 
on what goes on during a given request - and there would be no reason to have two 
content inbound lists active for a given request. 

Applicant also notes that he respectfully disagrees with the examiner's assertion 
that the claim limitation of claim 1 "the unfriendly outbound list, the friendly inbound 
list, the unfriendly inbound list, being uniquely configured for each user account" is met 
by the combination of Gate, Humes and Cirasole, and in particular the assertion that 
Cirasole teaches this element. In fact, Cirasole does not teach the limitation that the 
friendly inbound list and the unfriendly inbound list are uniquely configured for each user 
account. As seen from FIG. 6 blocks 254 and 255 of Cirasole, Cirasole teaches only two 
lists (personal exclusive and personal inclusive) and. they are for protecting resources. 
Consequently, the claim limitation of two inbound lists - friendly and unfriendly - 
uniquely configured for each user account is not taught by Cirasole. 

The dependent claims 2-3, 6, 9-13, 17-54 are distinguishable over the prior art 
because they are dependent on independent claims 1 and 14 which themselves are 
distinguishable over the prior art. In addition, as described below, many of the dependent 
claims are also distinguishable over the prior art for additional reasons. 
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Furthermore, with respect to claims 13 and 14, which recite content filtering, 
Applicant respectfully disagrees with the examiner's assertion that the cited prior art, and 
in particular Humes, teaches this limitation. For example, in contrast to the claimed 
invention of claims 13-14, in which content filtering requires "checking a conte nt of a 
requested document " against friendly and unfriendly inbound lists, according to the claim 
limitations recited in these claims, Humes merely checks URL s. See Humes column 6 
lines 1.8-34 and in particular lines 18-21 and 28-32, For example, Humes states 
"[d]ecision block 314 asks whether the requested URL is in the Local- Allow list, which 
is a list of URLs associated with web pages. ■ .and If the URL is in the Local-Allow 
list., .If the URL is not in the Local- Allow list, decision block 320 checks to see if the 
URL is in the Deny List. The Deny List is a listing of URLs associated with . . . The 
claimed invention of claim 13, moreover, checks URLs separately as required by its 
domain filtering limitations. Accordingly, claims 13 and 14 and claims dependent on 
claim 14, are distinguishable over the prior art for the additional reason that the claimed 
limitations of content filtering are not met by the cited prior art. 

Regarding claim 19, Humes does not meet the limitations of the claim which 
recites three paths: (1) approving the request, (2) terminating the request and (3) 
terminating and re-routing the request. As seen in Humes Figure 2, in either conditional 
blocks 214 (domain filtering), and even 220 (content filtering, which is irrelevant to 
claim 19), there are 2 exit paths, as YES blocks (216, and 222), and NO blocks (218, and 
224). Similarly, as seen in Humes Figure 3, in his either domain filtering conditional 
blocks 314, and 320, there are 2 exit paths, as YES blocks (3 1 6, and 322), and NO blocks 
(320, and 324). See Humes column 6, lines 18-38. There is no third path. Accordingly, 
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claim 19 is distinguishable over the prior art cited for this additional reason. 

Regarding claim 20, the Humes design "shows that a page indicating access is 
forbidden" (see Humes column 5 lines 10-19). While this teaches an alert it does not 
teach passing the request and alerting. Accordingly, claim 20 is distinguishable over the 
prior art for this additional reason. 

Regarding claim 21, the cited part of Humes only teaches a forbidden page and 
does not teach the limitations of the claim and is distinguishable over the prior art for this 
additional reason. 

Claim 23 has been amended to make clear that in contrast to this claim, the child's 
authorized Buddy List of Gantz is referring to human resources and not to web resources. 
Accordingly, claim 23 is distinguishable over the prior art for this additional reason. 

Regarding claim 32, the examiner cited paragraph 0075 of Gatz. However, this 
paragraph does not support Gatz being capable of checking the identity of a requesting 
client against the friendly and unfriendly inbound lists and against the domain inbound 
exception list. Gatz cannot do that. 

Regarding claims 33-34, the Humes design "shows that a page indicating access 
is forbidden" (see Humes column 5 lines 10-19). While this teaches an alert it does not 
teach passing the request and alerting. Accordingly, claims 33-34 are distinguishable 
over the prior art for this additional reason. Furthermore, regarding claim 33 , Gatz 
teaches (see Gatz para. 0075-0076) that the parent has the power to overrule whereas the 
claims recites that the outbound or inbound exception list overrules. Accordingly, claim 
33 is distinguishable over the prior art for this additional reason. 
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Regarding claims 35-36, while the claim dictates that the software is programmed 
to £check] an identity of a requesting client", Gatz does not support client application 
authentication. 5 ' See Gatz para, 0061 and FIG. 6 items 84, 85, Gatz design does not 
support client application authentication and is inconsistent regarding the type of clients. 
For example, Gatz calls user computers "clients" 212(1) through 212(N). See Gatz "user 
computer" 212(1) thru 212(N) in Figure 2, and [0045], particularly, lines 1-3 but he calls 
his 212 a "user," See Gatz [0044], He calls a client as: "Client Computer Devices 8, 10 

See [0042], as well as Figure 1. He further, calls a client as: "HTTP client 212. . 
See [0045], and Figure 2, Gatz also discloses: . . user computer system or device 212 to 
have basic hardware , . . having display screen. . . " - as seen in Figure 2 See Gatz 
[0050], Gatz also discloses device 212 to have input devices as well as output devices. 
See Gatz [0051], and [0052], There is a confusion regarding the client host and client 
application. In any event, Gatz design never discloses any type of client identity or client 
application identity authentication, which is extremely important when multiple 
applications may share same client host identities. Client application identity is 
important since the use of client application identity includes vendors' information, 
version, client host information, and even hardware information. The client application 
information will be used for many reasons, such as: a) session information - for security 
reasons-; b) for client host IP address and domain name; c) to resolve the type of client 
application (i.e., which browser type) in order to allow the responding server to provide 
appropriate responses for Presentation Support, and d) etc. There are more than a dozen 
browsers available in the smart phone market; each supports a different presentation 
format. The server has to know the type and version of the browser to properly send the 



25 



response. Since Gatz does not teach client application authentication, this is an additional 
reason why claims 35-36 are distinguishable over the prior art and should be allowed. 

Regarding claims 40-41, the claimed elements are not met by Gatz paragraph 
0073, as asserted by the examiner. Gatz merely teaches the well known idea of blocking 
emails with inappropriate language or email attachments. It does not teach having emails 
inaccessible to a user or deleting them. 

Regarding claims 42-44, Applicant does not believe that Cirasole is consistent 
with the limitations of these claims. For example, Cirasole uses TCP request packets in 
his filtering inspected and not HTTP packets. See Cirasole, column 5, lines 60-67, 
Therefore, Cirasole may not be compatible with content based access management and a 
domain filtering system such as discussed under claim 1, and the additional content 
exception lists in this claim. In addition, the claimed invention (claim 42) has two 
personal hard friendly/unfriendly content exception list, 2 personal soft 
friendly/unfriendly content exception lists. Claim 13 has 2 personal friendly/unfriendly 
content lists. Claim 1 has 2 personal inbound friendly/unfriendly domain lists and 2 
personal outbound friendly/unfriendly domain lists. In total, claim 42 requires 4 personal 
domain and 6 personal content lists. In Cirasole, in contrast, there are 2 personal address 
lists as well as one common address list, See sections 2.4(a), 2.4(g), 2.4(h), and 2,4(i). 
See Cirasole Column 6, lines 1-13, 

Regarding claim 9, Applicant has amended this claim to more clearly recite that 
the encryption function is capable of encrypting only a portion of the email message, the 
portion being selected by the user. This amendment is less ambiguous and distinguishes 
over Gennaro and the other prior art. Gennaro does not teach that the user can select 
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what portion of the email message to encrypt and the encryption function can then 
encrypt only that portion. This provides an advantage over data mining programs without 
having to encrypt the entire message. In addition, Applicant has deleted the limitation 
that the encryption function "generates one or more secret symmetric encryption keys, 
the one or more encryption keys being uniquely associated with a text presented by a user 
of the editing pane" and placed that into new claim 56. 

Applicant has amended claim 6 to delete the last limitation. Applicant has also 
amended claims 12, 18, 30-33, 35-36, 46 and 50-51. For example, claim 12 has been 
amended to recite at least one of an option of hard email filtering and an option of soft 
filtering rather than both. Claim 35-36, 50-51 have been amended to change "at least one 
of \a requesting client and a requested resource rather than one or the other. Claims 18 
and 46 have been amended to include at least one of hard and soft filtering instead of 
only one of them. Claim 46 has also been amended for clarity by changing "can" to "is 
able to". Claims 32-33 have been amended to change the claim from which these claims 
depend. 

In response to the examiner's double patenting rejection of claim 1, Applicant has 
provided a terminal disclaimer with respect to claim 1 of US Patent No. 7,587,499 (the 
parent). 
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It is respectfully requested that claims l-3 ? 6, 9-14, 17-57, which are understood 
to be in condition for allowance, be allowed. 
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